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REAL PARTY IN INTEREST 

The real party in interest in this case is Insors Integrated Communications, 
111 W. Jackson, #1412, Chicago, Illinois 60604-3589. 
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RELATED APPEALS AND INTERFERENCES 

There are no other appeals or interferences related to this application. 
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STATUS OF CLAIMS 

The current status of the claims are as follows: claims 1-17, 19-20, and 22- 
37 are pending. Claims 18 and 21 have been cancelled. No claims have been allowed. 
Claims 1-17, 19-20 and 22-37 stand finally rejected. The rejections of claims 1-17, 19-20 
and 22-37 are appealed. 
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STATUS OF AMENDMENTS 

Amendment A was filed on July 18, 2008 in response to a non-final Office 
Action mailed on March 19, 2008. Amendment B was filed on February 24, 2009 in 
response to a Final Office Action mailed on November 24, 2008, and was the last 
amendment filed. For the purpose of appeal, Amendment B was not entered. 1 No 
amendments were filed subsequent to Amendment B. An Advisory Action was mailed 
on March 2, 2009 indicating that Amendment B would not be entered. 



1 The Advisory Action indicated that amendments to claims 1, 4, 6, 7, 36 and 37 were sufficient to overcome the 
§112 rejections of these claims, while amendments to other claims were not acceptable. It is therefore assumed that 
the amendments to claim 1, 4, 6, 7, 36 and 37 will be entered. 
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SUMMARY OF CLAIMED SUBJECT MATTER 

The claims under appeal are reproduced below (including independent 
claims to be considered at appeal and dependent claims which are argued separately in 
accordance with §41.37 C(l)(v)), with bracketed insertions referring to the associated 
portions of the written description and/or drawings of the above-named application. 

Claim 1 . A method for organizing a virtual meeting between a plurality 
of attendees on a computer network, the method comprising the steps of: 

selecting a meeting date, a meeting start time, meeting duration, and a 
meeting code [page 6, lines 19-25; Figure 3A, block 30], storing said meeting date, said 
meeting start time, said meeting duration, and said meeting code in a meeting file [page 
9, lines 3-6; Figure 3A, block 36]; 

storing said meeting file in a memory accessible to the network [page 2, 
lines 26-29; page 9, lines 3-6; Figure 3 A, block 36; page 11, lines 28-30]; 

communicating a meeting invitation to said plurality of attendees over the 
network, said invitation including at least said meeting date, said meeting start time, said 
meeting code, and a meeting entry portal [page 9, lines 6-8; Figure 3 A, block 38], 

receiving a request to join the meeting from a first of said plurality of 
attendees [page 9, lines 23-25; Figure 3B, block 40]; 

allocating network resources for said meeting after receiving said request to 
join from said first of said plurality of attendees [page 11, lines 7-14], said network 
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resources including at least a network interface location for connecting said plurality of 
attendees for communication with one another during the meeting [page 5, lines 6-30; 
page 10, lines 12-23; Figure 3B, blocks 50 and 52], said network resources sufficient to 
communicate a plurality of real time data streams over the network, said plurality of real 
time data streams including at least one real time video data stream and at least one real 
time audio data stream [page 5, lines 6-30; page 8, lines 1-19; Figure 3A, block 32; 
Figure 5]. 

Claim 6. A method as defined by claim 1 and further including the 
steps of determining the total bandwidth available to communicate with each of said 
plurality of attendees through consideration of whether additional traffic unrelated to the 
virtual meeting will be carried over a linkage connecting said at least one meeting 
attendee to the virtual meeting [page 13, lines 3-11; page 13, lines 28-30; Figure 6, block 
102; page 14, line 2]. 

Claim 11. A method as defined by claim 1 and further including the 
steps of determining the total required bandwidth for the meeting [page 12, lines 23-30; 
page 13, lines 1-2; Figure 6, block 100], of determining the total bandwidth of each of 
said plurality of meeting attendees [page 13, lines 3-22; Figure 6, block 102; page 14, line 
2], and of limiting said meeting attendees to only those having sufficient bandwidth to 
participate in said meeting [page 14, lines 1-5; Figure 6, blocks 104, 106 and 108]. 



7 



Claim 12. A method as defined by claim 1 and further including the 
steps of determining the total required bandwidth for the meeting [page 12, lines 23-30; 
page 13, lines 1-2; Figure 6, block 100], of determining the total available bandwidth of 
each of said plurality of meeting attendees [page 13, lines 28-30; page 14, line 2; Figure 
6, block 102, and of directing any attendees that do not have sufficient bandwidth 
available to link to a subset of said plurality of data streams being communicated during 
the meeting [page 14, lines 8-10]. 

Claim 14. A method as defined by claim 1 wherein said invitation is an 
executable file that upon execution takes steps necessary to connect to said virtual 
meeting [page 9, lines 17-19]. 

Claim 27. A method as defined by claim 1 wherein said meeting entry 
portal is a URL [page 9, lines 8-13; Figure 3 A, block 38] and wherein said network 
interface location is different from said meeting entry portal URL [page 10, lines 24-30; 
Figure 1; page 1 1, lines 1-6 and lines 13-15; Figure 3B, block 54]. 

Claim 28. A method as defined by claim 1 and further including the step 
of specifying an early join time before said start time before which said at least one 
attendee cannot join the meeting and a late time after which said at least one attendee 
cannot join the meeting [page 7, lines 3-10; page 9, lines 28-30; Figure 3B, blocks 42 and 
44]. 
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Claim 31. A computer program product for organizing a virtual meeting 
between a plurality of attendees on a computer network, the program product including 
computer executable instructions stored on a computer readable medium that when 
executed cause the computer to [page 6, lines 3-12]: 

receive a meeting code, a meeting date, a meeting start time [page 6, lines 19-25 
and lines 32-35; Figure 3A, block 30], and the identity of a plurality of meeting attendees 
from a user submitted over the network [page 7, lines 12-16; page 10, lines 1-7; Figure 
3 A, block 30]; 

store said meeting code, said meeting start time, and said identity of said 
plurality of meeting attendees in a meeting file in a memory accessible to the network 
[page 9, lines 3-6; Figure 3 A, block 36; page 11, lines 28-30]; 

communicate an invitation to each of said plurality of meeting attendees, 
said invitation including at least said meeting start time, said meeting code, and an entry 
portal for entering the meeting [page 9, lines 6-8; Figure 3 A, block 38]; 

receive a first request to enter the meeting from a first of said plurality of 
meeting attendees after said first attendee has connected to said entry portal [page 9, lines 
23-25; Figure 3B, block 40], allocating at least one network interface location for the 
meeting after receiving said first request [page 11, lines 7-15; Figure 3B, block 52], said 
at least one network interface location sufficient to link a plurality of real time video 
streams and at least one real time audio stream between each of said plurality of meeting 
attendees [page 5, lines 6-30; page 8, lines 1-19; Figure 3A, block 32; Figure 5], storing 



said at least one network interface location in said meeting file [page 11, lines 28-30, 
Figure 3B, block 52], linking said first meeting attendee to said network interface [page 
10, lines 17-23; page 11, lines 7-14; Figure 3B, blocks 52 and 54]; and, 

receiving a subsequent request from a second of said plurality of meeting 
attendees [page 11, line 10; Figure 3B, block 54], and linking said second meeting 
attendee to said network location [page 10, lines 17-23; page 11, lines 7-14; Figure 3B, 
blocks 52 and 54]. 

Claim 34. A computer program product as defined by claim 31 wherein 
the program instructions further cause the computer to determine the total bandwidth 
required to participate in said meeting [page 12, lines 23-30; page 13, lines 1-2; Figure 6, 
block 100], and the bandwidth available to communicate with each of said plurality of 
meeting attendees [page 13, lines 3-30; Figure 6, block 102]. 

Claim 35. A computer program product as defined by claim 31 wherein 
the program instructions when executed further cause the computer to determine the 
bandwidth resources for each of said plurality of meeting attendees [page 13, lines 3-30; 
Figure 6, block 102]. 
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GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 



1. The rejection under 35 U.S.C. § 102(a) of claims 1-5, 11-17, 19-20, 
22-27 and 29-37 over Semaan (U.S. 5,680,392) is to be reviewed on appeal. 

2. The rejection under 35 U.S.C. § 103(a) of claims 6-10 as over 
Semaan in view of Etorre (U.S. 6,594,265) is to be reviewed on appeal. 

3. The rejection under 35 U.S.C. §103(a) of claim 28 over Semaan in 
view of Blinken (U.S. 6,594,265) is to be reviewed on appeal. 
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ARGUMENT 

The present invention provides methods and program products for 
organizing virtual meetings between a plurality of attendees on a computer 
network, with an example virtual meeting being a videoconference between a 
plurality of users. [Page 4, line 15-20] As explained in the background section 
of the specification, prior to the present invention organizing virtual meetings such 
as a videoconference can be cumbersome. [Page 2, line 3-20] Some prior art 
systems and methods, for example, can require reserving a network address for the 
meeting well before the meeting and letting users know in advance of the meeting 
what address has been reserved. [Page 1, lines 29-3 1] This is particularly the case 
when a virtual meeting such as a videoconference includes attendees numbering 
into the hundreds or even thousands. [Page 2, line 17-18]. 

The present invention addresses these and other problems by 
providing methods and program products for organizing virtual meetings over a 
data network, with an example being a video conference. [(Page 4, line 15-20] 
An important aspect of some claimed embodiments is allocating at least some 
network resources, with some claims reciting a network interface location for the 
meeting, after receiving a request to join the meeting. [Page 11, line 7-17] This 
has been discovered to be advantageous over the prior art. Network addresses are 
not pre-reserved for meetings that might not occur for one reason or another, but 
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instead remain freely available until they are actually required. [Page 10, line 10- 
12] 

The Final Office Action finally rejected claims 1-5, 11-17, 19-20, 
22-27 and 29-37 as anticipated by Semaan, and finally rejected claims 6-10, 28 
and 34 as obvious over Semaan in view of second references. [Final Office 
Action, para. 10, 12-13.] Semaan is accordingly the primary reference relied upon 
for all rejections. Semaan, however, fails to disclose or suggest multiple elements 
that the Examiner alleges it to. 

Importantly, Semaan teaches a reservation system for reserving 
MCU and other resources useful to conduct audio and video conferences. 
[Semaan, Abstract] This is different than many claimed embodiments, which are 
directed to methods and program products for organizing virtual meetings (as 
opposed to making "reservations"). The claims require additional or different 
elements than are disclosed by Semaan. As will be explained in detail below 
Semaan is directed to making reservations, for example, and does not disclose or 
suggest allocating resources for the meeting after a request to join the meeting has 
been received (as recited by some but not all claims), determining bandwidth 
available for a particular user (as recited by some but not all claims), and other 
differences. 

Issues on this appeal include: 

I. Whether the anticipation rejection of claims 1-5, 11-17, 19-20, 22-27 and 29- 
37 over Semaan is proper. 
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1(A) Semaan fails to disclose allocating a network interface location for a 
meeting after receiving a first request to join the meeting as recited by 
independent claims 1 and 31 (as well as claims 2-5, 11-17, 19-20, 22- 
27, 29-30, and 32-36 that depend from these claims). 

1(B) Semaan fails to disclose communicating a meeting invitation that 
includes a meeting entry portal as recited by independent claims 1 and 
31 (as well as claims 2-5, 11-17, 19-20, 22-27, 29-30, and 32-36 that 
depend from these claims). 

1(C) Semaan fails to disclose determining available bandwidth as recited by 
claims 11, 12, 34 and 35. 

1(D) Semaan Fails to Disclose Directing Users with Insufficient 
Bandwidth to Link to a Subset of the Plurality of Data 
Streams as Recited by Claim 12 

1(E) Semaan fails to disclose an executable meeting invitation as recited by 
claim 14. 

1(F) Semaan fails to disclose communicating a meeting invitation including a 
URL meeting entry portal as recited by claim 27. 

II. Whether the rejection of claims 6-11 as obvious over Semaan in view of 
Etorre is proper - Semaan fails to disclose determining available bandwidth. 

III. Whether the rejection of claim 28 as obvious over Semaan in view of 
Blinken is proper. 

III(A) Semaan fails to disclose allocating a network interface location for a 
meeting after receiving a first request to join the meeting, 

III(B) Semaan fails to disclose communicating a meeting invitation that 
includes a meeting entry portal 



I. The Anticipation Rejection of Claims 1-5, 11-17, 19-20, 22-27 and 
29-37 as Anticipated over Semaan is Improper. 

Independent claims 1 and 31 as well as dependent claims 2-5, 1 1-17, 

19-20, 22-27, 29-30 and 32-37 stand rejected as anticipated by Semaan. 
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Argument regarding the appeal of these claims is presented for the claims as a 

group as called for by MPEP 1205.02(vii), with grounds of argument for particular 

claims to be considered separately presented using subheadings as called for by 

MPEP 1205.02(vii). 

"A claim is anticipated only if each and every element as set forth in 
the claim is found, either expressly or inherently described, in a single prior art 
reference." Verdegaal Bros. v. Union Oil Co. of California, 814 F.2d 628, 631, 2 
USPQ2d 1051, 1053 (Fed. Cir. 1987). "The identical invention must be shown in 
as complete detail as is contained in the ... claim." Richardson v. Suzuki Motor 
Co., 868 F.2d 1226, 1236, 9 USPQ2d 1913, 1920 (Fed. Cir. 1989). It is submitted 
that Semaan fails to disclose each and every element of claims 1-5, 11-17, 19-20, 
22-27 and 29-37; and that the anticipation of these claims is therefore improper 
and must be withdrawn. 

1(A) Semaan Fails to Disclose Allocating a Network Interface 
Location for a Meeting After Receiving a First Request to 
Join the Meeting as Recited by Independent Claims 1 and 31. 

Independent claims 1 and 31 stand rejected as anticipated over 
Semaan. Claim 1 recites, among other elements, that network resources are 
allocated after receiving a request to join the meeting. Similarly, independent 
claim 3 1 recites, among other elements, that a network interface location for the 
meeting be allocated after a first request to enter the meeting is received. 

Because both of these claims recite that network resources (claim 1) 
or a network interface (claim 31) is allocated only after the meeting is actually 
requested to begin, no network interface is "reserved" in advance. As explained in 
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the specification, this has been discovered to offer particular advantages and 

benefits over the prior art: 

In this manner the exemplary method of the invention only allocates a 
meeting address at the beginning of the meeting. That is, only when 
a first attendee requests entry to the meeting is the meeting address 
allocated. Second and subsequent attendees are then linked to that 
allocated address. It has been discovered that these preferred steps 
are advantageous for purposes of allowing meeting addresses to 
remain freely available until required. When resources are limited, 
this may be of particular benefit. 

Page 1 1, line 7 - line 14. 

Semaan fails to disclose these recited elements of claims 1 and 31, 

and in fact teaches away from them. As indicated by the title of Semaan 

("Multimedia Multipoint Telecommunications Reservation Systems"), it is 

entirely directed to methods for making reservations and reserving network 

resources, including a network interface (which is accepted to be an MCU only for 

the sake of argument) in advance of a meeting. For example; "It is a further object 

of the invention to provide a ... reservation system which will permit any 

multimedia user to reserve the resources of one or more MCU's for a multi-media 

conference." Col. 2, lines 48-52 (emphasis added). 

The Final Office Action cited col. 6, lines 20-52 of Semaan as 

disclosing this recited element. [Final Office Action, para. 10.] This section of 

Semaan, however, makes no such disclosure and instead describes various steps 

performed to reserve MCU resources in advance of a meeting: "...the reservation 

controller ... will make a determination as to whether the necessary MCU 
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resources will be available for the ... time requested. If so, the reservation 
controller will confirm the reservation.. ." Col. 6, lines 24-28 (emphasis added). 

Accordingly, Semaan teaches reserving particular MCU resources in 
advance of a meeting and fails to disclose or suggest the recited elements of claims 
1 and 31 of allocating a network interface only after a request to join the meeting 
has been received. Claims 1 and 3 1 are therefore allowable as are all claims that 
depend therefrom, and the corresponding anticipation rejection must be 
overturned. 

1(B) Semaan Fails to Disclose or Suggest Communicating a 
Meeting Invitation that Includes a Meeting Entry Portal as 
Recited by Independent Claims 1 and 31 

Other elements recited by claims 1 and 31 are not disclosed or 
suggested by Semaan. Independent claims 1 and 31 recite that a meeting 
invitation including a meeting entry portal be communicated to the attendees. 
Semaan fails to disclose or suggest this claimed element, with the result that no 
prima facie case of anticipation has been presented. 

The Final Office Action cites column 8, lines 51-64 as disclosing 
this element. [Final Office Action, para. 10.] It is submitted that this is incorrect - 
no such disclosure is made. Careful review of this portion of Semaan has been 
made without any identification of this recited element. Amendment A noted that 
this rejection was not supported by the citation and requested clarification on the 
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alleged disclosure of Semaan. Despite such request, the Final Office Action 
provided no further comment. 

Further, other portions of Semaan make clear that no meeting 
invitation including a meeting entry portal is communicated to users. As 
discussed above, Semaan teaches that at least some users are called from the MCU 
to initiate a conference: "...a list of users that will be automatically called when 
the conference is created." Col. 8, lines 58-59. Since they are called from the 
MCU, there is no need for them to know an entry portal, much less a need to 
communicate an executable invitation file to them including an entry portal. 

Semaan additionally teaches that users are "attached" to a permanent 

reservation domain, that all conferencing will occur over this known domain, and 

that users must know the address of the reservation domain: 

"(users) must know the address of the reservation domain and must 
attach themselves to the reservation domain . . . Once attached to the 
reservation domain, the user can make a reservation request by 
sending the reservation request onto the request channel ... In the 
situation where multiple reservation controllers are provided ... the 
user calls the address domain of the 'local' reservation controller in 
order to attach to the reservation domain ..." 

col. 3, lines 35-60 (emphasis added). 

No prima facie case of anticipation has been presented for claims 1 

and 31 since Semaan fails to disclose that a meeting invitation including a 

meeting entry portal be communicated to the attendees. Instead, Semaan teaches 

a method wherein users must know the address of their local MCU. This is very 

different from the claimed embodiment. This is another reason that the 
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anticipation rejection of independent claims 1 and 31 is improper. The rejection 
must therefore be overturned, and these claims as well as all others that depend 
from them are allowable. 

1(C) Semaan Fails to Disclose Determining Available Bandwidth as 
Recited by Claims 11, 12, 34 and 35. 

Claims 11, 12, 34 and 35 are allowable since they depend from 
independent claims 1 (claims 11, 12) or 31 (claims 34, 35). These claims are 
allowable on an independent basis as well. Claim 1 1 recites determining the total 
bandwidth available to communicate with the at least one meeting attendee. 
Claim 12 recites a step of determining the total available bandwidth of each of the 
plurality of meeting attendees. Claims 34 and 35 likewise recite that the computer 
program product causes the computer to perform a step of determining the 
bandwidth available to communicate with each of the plurality of meeting 
attendees. It is submitted that the rejection of these claims mistakenly confuses 
steps of determining bandwidth necessary with bandwidth available - these are 
two different things. 

In rejecting these claims, the Final Office Action cites portions of 
Semaan that discuss determining what MCU and other resources will be 
"necessary" for a particular meeting: " ...and the resources necessary for the 
conference." Col. 6, lines 12-13. [Final Office Action, para. 10.] These portions 
of Semaan do not disclose determining what bandwidth is available (as opposed to 
"necessary") over particular linkages. It is important to appreciate that these 
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claimed steps do not refer to determining bandwidth "necessary" but instead 
bandwidth "available." These are very different steps. By way of analogy, 
measuring bandwidth "available" determines "how much there is," which is 
different that measuring bandwidth "required" which equates to "how much is 
needed." 

Semaan fails to disclose determining bandwidth available, but 
instead discusses bandwidth required. This is another basis for overturning the 
anticipation rejections of claims 11, 12, 34 and 35. 

1(D) Semaan Fails to Disclose Directing Users with Insufficient 
Bandwidth to Link to a Subset of the Plurality of Data 
Streams as Recited by Claim 12. 

There is still another basis for the overturning of the anticipation 

rejection of claim 12 over Semaan. Claim 12 further recites: "... and of directing 

any attendees that do not have sufficient bandwidth available to link to a subset of 

said plurality of data streams being communicated during the meeting." The Final 

Office Action cites col. 6, lines 28-64 of Semaan as disclosing this. [Final Office 

Action, para. 10] No such disclosure is made, however. Careful review of this 

section of Semman indicates that it is related to determination of availability of 

MCU resources. No disclosure of directing users with insufficient bandwidth to 

link to a subset of data streams as is claimed. 
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1(E) Semaan Fails to Disclose or Suggest an Executable Meeting 
Invitation as Recited by Claim 14 

Claim 14 depends from claim 1 and is allowable for the same 
reasons as are that claim. The anticipation rejection of claim 14 over Semaan 
should be overturned for another reason as well. Claim 14 requires a step of 
communicating a meeting invitation to at least one attendee over the network that 
is an executable file that upon execution takes all steps necessary to connect to 
the virtual meeting. Semaan fails to disclose or suggest this required element. 

The Final Office Action alleges that Semaan discloses 
communicating an executable file invitation to attendees at column 8, lines 57-59 
to reject claim 14. [Final Office Action, para. 10.] This cited portion of Semaan, 
however, makes no such disclosure and instead indicates that Semaan teaches 
away from this claimed element since it discloses calling conference attendees 
from the MCU, not the users calling into the MCU: "The three lists preferably 
include a list of users that will be automatically called (from the MCU) when the 
conference is created..." Col. 8, lines 57-58 (emphasis added). 

Accordingly, instead of communicating an executable file to users 
that when executed by the user takes all steps necessary to connect the user to the 
conference, Semaan teaches a different approach that includes one or more lists of 
attendees being centrally stored and users on a list being "automatically called" 
from the MCU when the conference is created. Semaan therefore does not 
disclose or suggest the limitation of claim 14 of an executable invitation file that 
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takes steps to connect to the meeting from the attendee, and the anticipation 
rejection of this claim must be withdrawn. 



1(F) Semaan Fails to Disclose Communicating an Invitation 
Including a URL Meeting Entry Portal as Recited by Claim 
27. 

Claim 27 depends from claim 1 and further recites that the meeting 
entry portal is a URL, and that the meeting entry portal is different from the 
network interface. Semaan fails to disclose this, and this is therefore another 
reason that the anticipation rejection of claim 27 should be overturned. In 
rejecting claim 27, the Office Action mailed on March 19, 2008 cited col. 3, lines 
19-23 and col. 7, lines 42-52 of Semaan. [Office Action, page 8] Amendment A 
pointed out that these sections of Semaan failed to disclose a URL meeting entry 
portal, much less communicating an entry portal including a URL that is different 
from the network interface. [Amendment A, Section C.5] 

In response, the Final Office Action stated: 

"Semaan teaches 'must attach themselves ... by establishing one or 
more transport connections ... many of which are defined in ITU- 
TT.123 (col. 3, lines 37-50) 'transport protocols set forth in TT.123 
... TCP / IP (the internet) (col. 7, lines 42-46), where 'attached' also 
being defined in T.122 (col. 3, lines 38-39). It is old and well 
known in the art that URL is inherent to the use of TCP / IP. It 
is noted that it is old and well known that the under (sic) ITU - 
T T.122 'attach' means to connect. Therefore the (sic) Semaan 
teaches a meeting invitation including a meeting entry portal is a 
URL (URL for attachment) to be communicated to the attendee 
(made known)." 

[Final Office Action, para. 10.] (emphasis added). 
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This explanation is not completely clear, but to the extent that it is 
understood, it appears that the Examiner alleges that because Semaan discloses 
users attaching to a domain using TCP / IP, it "inherently" discloses the claimed 
step of claim 27 (depending form claim 1) of: "communicating an invitation to 
said plurality of attendees over the network, ... including a ... meeting entry portal, 
.... and wherein said meeting entry portal is a URL and wherein said network 
interface location is different from said meeting entry portal URL." It is submitted 
that this rejection represents a highly conclusory analysis, and is improper on 
multiple basis. 

No reference has been cited for the proposition that "attaching" 
using the well known TCP / IP protocol "inherently" teaches communicating a 
meeting invitation that includes a URL. Admittedly, TCP (transmission control 
protocol) and IP (internet protocol) are well known protocols for communicating 
packetized data over networks. As is well known in the art, however, there are an 
infinite number of operations using these protocols that have nothing to do with 
URL's, much less communicating a meeting invitation to a user that include a 
meeting entry portal that is a URL. 

The Examiner's highly conclusory rejection has been made without 
citation to any reference. Under the circumstances, this is improper: "It would not 
be appropriate for the examiner to take official notice of facts without citing a 
prior art reference where the facts asserted to be well known are not capable of 
instant and unquestionable demonstration as being well-known." MPEP 
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§2144.03(A); "... when an examiner relies on a scientific theory, evidentiary 
support for the existence and meaning of that theory must be provided." MPEP 
2144.02, citing In re Grose, 592 F.2d 1 161, 201 USPQ 57 (CCPA 1979). 

It is submitted that the allegation that communication of an 
invitation including a meeting entry portal that is a URL "inherently" follows from 
a teaching of using TCP / IP to attach to a meeting is not capable of instant and 
unquestionable demonstration as being well known, and that this rejection is 
therefore improper under MPEP and case law precedent. MPEP §2144. 03(A); 
MPEP 2144.02; In re Grose, 592 F.2d 1 161, 201 USPQ 57 (CCPA 1979). 

Further, even in the unlikely event that the improper and conclusory 
"inherent" analysis of the Examiner's rejection were to stand, the rejection would 
be improper for other reasons as well. In particular, claim 27 requires more than 
just communicating an invitation including a URL to attendees. It further recites 
that: "...said network interface location (where users are connected to one another 
for the conference) is different from said meeting entry portal URL." (emphasis 
added). The specification explains that this has particular benefits and advantages: 
"Also, use of a meeting entry portal that is separate from the meeting address at 
which the meeting will be conducted has been found to offer benefits and 
advantages. The meeting entry portal can be constant from meeting to meeting, 
while the meeting address for the meetings is not required to be." [Page 11, line 
14-17]. 
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Semaan fails to disclose this, and the Final Office Action fails to cite 
any portion of Semaan (or any other reference) allegedly doing so. The Examiner, 
in fact, has failed to make any reference to this element of claim 27. This is yet 
another reason that no prima facie case for anticipation has been made. 

Finally, as discussed above in Section 1(B), Semaan teaches that 
users must know the address of the reservation domain: "(users) must know the 
address of the reservation domain and must attach themselves to the reservation 
domain ..." col. 3, lines 35-38 (emphasis added). Accordingly, it is clear that 
Semaan fails to teach communicating a meeting invitation to attendees at all, much 
less communicating one that includes a URL that is different from a meeting 
network interface location as required by claim 27. 

These are additional reasons that the rejection of claim 27 is 
improper and must be overturned. 

II. The Rejection of Claims 6-10 as Obvious over Semaan in View of 
Torre is Improper - No Prima Facie CAse of Obviousness has 
been Established since Semaan Fails to Disclose or Suggest 
Determining Available Bandwidth. 

Claims 6-10 stand rejected as obvious over Semaan in view of Torre. 

Claims 7-10 depend from claim 6, and these claims are argued as a group together 

with claim 6 as permitted by MPEP 1205.02(vii). It is submitted that no prima 

facie case of obviousness has been presented and the rejection should be 

overturned. Claim 6 depends from claim 1 and recites "determining the total 
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bandwidth available to communicate with each of the plurality of meeting 
attendees." The Final Office Action cites Semaan as disclosing this element. As 
discussed in Section 1(C) above, however, Semaan fails to disclose or suggest this 
claimed step, but instead teaches determining the total bandwidth "necessary." 
This is very different from determining what is "available." 

In rejecting claim 6, the Final Office Action cites portions of 
Semaan that discuss determining what MCU and other resources will be 
"necessary" for a particular meeting: " ...and the resources necessary for the 
conference." Col. 6, lines 12-13 (emphasis added). [Final Office Action, para. 
10] These portions of Semaan do not disclose determining what bandwidth is 
available (as opposed to "necessary") over particular linkages. As discussed 
above, it is important to appreciate the significant differences between determining 
bandwidth "necessary" (as Semaan teaches) and bandwidth "available" (as 
claimed). Because Semaan fails to disclose or suggest this required step, no prima 
facie case of obviousness has been made and the rejection of claim 6 and claims 7- 
10 that depend therefrom are improper and must be overturned. 

III. The Rejection of Claim 28 as Obvious Over Semaan in View of 
Blinken is Improper. 

Claim 28 depends from claim 1 and stands rejected as obvious over 

Semaan in view of Blinken. Because claim 28 depends from claim 1, it includes 

the limitations of that claim. In the rejection of claim 28, Semaan is cited as 
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disclosing the elements of claim 1. As discussed above, these elements are not 
disclosed or suggested by Semaan. No prima facie case of obviousness has 
therefore been made regarding claim 28. For the sake of brevity, the details of 
argument with regard to Semaan' s failure to disclose the elements of claim 1 are 
not repeated here, but instead reference is made to sections 1(A) (Semaan fails to 
disclose allocating a network interface location for a meeting after receiving a first 
request to join the meeting) and 1(B) (Semaan fails to disclose communicating a 
meeting invitation that includes a meeting entry portal) herein above. 
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CONCLUSION 

For the foregoing reasons, Applicants respectfully request that the 
rejections of all claims be reversed, with instructions to allow this application. 
Reversal of the rejections of these claims is called for based on at least the 
following reasons: 

I. The Anticipation Rejection of Claims 1-5, 11-17, 19-20, 22-27 and 29-37 as 
Anticipated over Semaan is Improper: 

(A) Semaan Fails to Disclose Allocating a Network Interface Location for a 
Meeting After Receiving a First Request to Join the Meeting as Recited by 
Claims 1 and 3 1 . 

(B) Semaan Fails to Disclose or Suggest Communicating a Meeting 
Invitation that Includes a Meeting Entry Portal as Recited by Independent 
Claims 1 and 3 1 . 

(C) Semaan Fails to Disclose Determining Available Bandwidth as Recited 
by Claims 11, 12, 34 and 35. 

(D) Semaan Fails to Disclose Directing Users with Insufficient Bandwidth to 
Link to a Subset of the Plurality of Data Streams as Recited by Claim 12. 

(E) Semaan Fails to Disclose or Suggest an Executable Meeting Invitation as 
Recited by Claim 14. 

(F) Semaan Fails to Disclose a URL Meeting Entry Portal as Recited by 
Claim 27. 

II. The Rejection of Claims 6-10 as Obvious over Semaan in View of Torre is 
Improper - No Prima Facie Case of Obviousness has been made since 
Semaan Fails to Disclose or Suggest Determining Available Bandwidth. 

III. The Rejection of Claim 28 as Obvious over Semaan in View of Blinken is 
Improper. 

(A) Semaan Fails to Disclose Allocating a network interface location for a 
meeting after receiving a First request to join the meeting. 
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(B) Semaan fails to disclose communicating a meeting invitation that 
includes a meeting entry portal. 



April 22, 2009 
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CLAIMS APPENDIX 

1 . A method for organizing a virtual meeting between a plurality 
of attendees on a computer network, the method comprising the steps of: 

selecting a meeting date, a meeting start time, meeting duration, and 
a meeting code, storing said meeting date, said meeting start time, said meeting 
duration, and said meeting code in a meeting file; 

storing said meeting file in a memory accessible to the network; 

communicating a meeting invitation to said plurality of attendees 
over the network, said invitation including at least said meeting date, said meeting 
start time, said meeting code, and a meeting entry portal, 

receiving a request to join the meeting from a first of said plurality 

of attendees; 

allocating network resources for said meeting after receiving said 
request to join said meeting from said first of said plurality of attendees, said 
network resources including at least a network interface location for connecting 
said plurality of attendees for communication with one another during the 
meeting, said network resources sufficient to communicate a plurality of real time 
data streams over the network, said plurality of real time data streams including at 
least one real time video data stream and at least one real time audio data stream. 



30 



6. A method as defined by claim 1 and further including the 
steps of determining the total bandwidth available to communicate with each of 
said plurality of attendees through consideration of whether additional traffic 
unrelated to the virtual meeting will be carried over a linkage connecting said each 
of said plurality of attendees to the virtual meeting. 

11. A method as defined by claim 1 and further including the 
steps of determining the total required bandwidth for the meeting, of determining 
the total bandwidth of each of said plurality of meeting attendees, and of limiting 
said meeting attendees to only those having sufficient bandwidth to participate in 
said meeting. 

12. A method as defined by claim 1 and further including the 
steps of determining the total required bandwidth for the meeting, of determining 
the total available bandwidth of each of said plurality of meeting attendees, and of 
directing any attendees that do not have sufficient bandwidth available to link to a 
subset of said plurality of data streams being communicated during the meeting. 

14. A method as defined by claim 1 wherein said invitation is an 
executable file that upon execution takes steps necessary to connect to said virtual 
meeting. 
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27. A method as defined by claim 1 wherein said meeting entry 
portal is a URL and wherein said network interface location is different from said 
meeting entry portal URL. 

28. A method as defined by claim 1 and further including the step 
of specifying an early join time before said start time before which said at least 
one attendee cannot join the meeting and a late time after which said at least one 
attendee cannot join the meeting. 

31. A computer program product for organizing a virtual meeting 
between a plurality of attendees on a computer network, the program product 
including computer executable instructions stored on a computer readable medium 
that when executed cause the computer to: 

receive a meeting code, a meeting date, a meeting start time, and the 
identity of a plurality of meeting attendees from a user submitted over the 
network; 

store said meeting code, said meeting start time, and said identity of 
said plurality of meeting attendees in a meeting file in a memory accessible to the 
network; 
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communicate an invitation to each of said plurality of meeting 
attendees, said invitation including at least said meeting start time, said meeting 
code, and an entry portal for entering the meeting; 

receive a first request to enter the meeting from a first of said 
plurality of meeting attendees after said first attendee has connected to said entry 
portal, allocating at least one network interface location for the meeting after 
receiving said first request, said at least one network interface location sufficient 
to link a plurality of real time video streams and at least one real time audio stream 
between each of said plurality of meeting attendees, storing said at least one 
network interface location in said meeting file, linking said first meeting attendee 
to said network interface; and, 

receiving a subsequent request from a second of said plurality of 
meeting attendees, and linking said second meeting attendee to said network 
location. 

34. A computer program product as defined by claim 3 1 wherein 
the program instructions further cause the computer to determine the total 
bandwidth required to participate in said meeting, and the bandwidth available to 
communicate with each of said plurality of meeting attendees. 
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35. A computer program product as defined by claim 31 wherein 
the program instructions when executed further cause the computer to determine 
the bandwidth resources for each of said plurality of meeting attendees. 
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EVIDENCE APPENDIX 



None. 
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RELATED PROCEEDINGS APPENDIX 



None. 
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